DATA STRUCTURE FOR CONTROL INFORMATION ON REWRITEABLE 
DATA STORAGE MEDIA 



CROSS-REFERENCE TO RELATED APPLICATIONS 

The present application is a divisional application of serial number 
09/301,880 (filed 04/29/99). Application serial number 09/301,880 is hereby 
incorporated herein by reference. 

FIELD OF INVENTION 

This invention relates generally to data storage media and more specifically 
to data structures used for various identification and control attributes for a 
rewriteable medium. 

BACKGROUND OF THE INVENTION 

A data storage medium typically includes an area for storage of various 
administration and control information, such as an identification of the medium, 
perhaps information regarding how the medium is partitioned into various separate 
sections, a directory or table of file names and dates, and perhaps information 
regarding access control. Administration and control information may reside in a 
particular physical location on a mediimi separate from a general data storage area. 
For example, compact discs (CD) used for data storage have a single spiral track, 
with an area near the start of the track called a lead-in area, and an area near the 
end of the track called a lead-out area. The information in the lead-in area and the 
lead-out area contains administration and control information used only by drives 
and operating systems, and is separate from the area used for data storage. 
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Sometimes, a data storage medium has a format that is specific to a 
proprietary drive mechanism, or specific to one computer operating system. 
Alternatively, some formats are defined by standards, so that a medium can be 
exchanged among drives from multiple manufacturers and may be used by multiple 
5 computer operating systems. Standards are useful in eliminating unnecessary 

variation, but standards may also inhibit change, even when change is needed. For 
example, CD's were originally developed for read-only digital audio. As the CD 
technology was extended to general data, and write-once media, and rewriteable 

C3 media, accommodation of new features with backwards compatibility was always an 

v3 

3g issue. There is a need for a standard way of recording admimstration and control 

information, for interchangeable rewriteable media, that can accommodate 
C3 unforseen needs for changes in the future. 



□ 



SUMMARY OF THE INVENTION 



One goal of the invention is to provide a standard, but very general and 
2 flexible, data stmcture for recording administration and control information for a 

rewriteable storage medium, particularly when drives and media may be provided 
by many different manufacturers. Accordingly, a data structure, called a Disk 
20 Control Block (DCB), is defined. One medium may contain multiple different 

DCB's, each addressing a different function. Several examples of DCB's are 
provided. One example is called a General Media (GM) DCB. The GM DCB 
contains information such as a counter that counts how many times the medium has 
been loaded, control information for formatting of the medium by the drive, and 
25 power calibration information. Another example DCB is called an Access Control 

(AC) DCB. An AC DCB may be used to partition a disk into multiple sections, and 
for each section the DCB defines an access attribute such as write-once, or read 
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only with password, or other similar access control. Another example is a DCB for 
updating firmware. 

Another goal of the invention is to provide a data structure such that if a 
drive encounters an unrecognized DCB, the drive can still decode an essential set of 
standard control parameters in the unrecognized DCB, so that the drive behavior is 
not inconsistent with the requirements of the unrecognized DCB. Each DCB 
includes a control block identifier that specifies the function of the DCB. Each DCB 
also includes an area called Unknown Content Descriptor Actions (UCDA), which 
specifies certain actions a drive must take if the drive does not recognize the 
identifier for the DCB. 

An additional goal of the invention is to ensure the reliability of DCB's even 
if the disk is defective, or even if power is interrupted during writing of a DCB. In 
an example embodiment, redundant DCB's are provided, and each DCB has a 
sequence number. Identical identifiers with identical sequence numbers indicate 
identical (deliberately redundant) DCB's. If one copy is invalid, the invalid copy is 
replaced by the valid copy. Identical identifiers with different sequence numbers 
indicate that writing of a DCB was interrupted, and the DCB having the oldest 
(lowest) sequence number, for the particular identifier, is used. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a plan view of an optical disk in accordance with the invention. 

Figure 2 is a block diagram of a Disk Control Block in accordance with the 
invention. 

Figure 3 is a block diagram of a General Media Disk Control Block in accordance 
with the invention. 
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Figure 4 is a flow diagram of a method for using unknown Disk Control Blocks. 

Figure 5 is a flow diagram of a process for recovery from power-failure or data 
corruption in accordance with the invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE 



1Qy INVENTION 
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In the following discussion, a proposed standard for optical disk media is 
used to illustrate a specific example embodiment of the invention. However, the 
a invention is equally applicable to any interchangeable rewriteable data storage 

lis medium. For example, the invention is equally applicable to tapes, removable 

^f- magnetic disks or cards, or removable semiconductor memory. 

£3 The proposed standard specifies a rewriteable interchangeable optical disk. 

A data structure called a Disk Control Block (DCB) is defined. There may be many 
types of DCB's; some may be defined by the proposed standard, and others may be 
20 defined by individual manufacturers. One type of DCB, called a General Media 

(GM) DCB is defined by the proposed standard. The proposed standard specifies 
that every compatible medium must write one GM-DCB. All other types of DCB's 
are optional, and are in addition to the GM-DCB. 

The proposed optical disk medium is formatted into sectors, and sectors are 
25 logically grouped into blocks. In the proposed standard, each sector is 2 Kbytes 

(2,048 bytes) and each block is 16 sectors. A block is the smallest unit of data that 
can be written. Error correction is performed on a block by block basis. In the 
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proposed standard, a DCB is one block. In the specific example embodiment, 
DCB's reside within the lead-in and lead-out areas of an optical disk. 

Figure 1 illustrates the proposed disk medium. The proposed disk 100 has a 
single spiral track 102, starting at an inner diameter and ending at an outer 
diameter. The spiral track has at least one lead-in area 104 and at least one lead-out 
area 106. One copy (108) of each DCB is written in the lead-in area, and a 
redundant copy (110) is written in the lead-out area. In the proposed standard, each 
lead-in or lead-out area can accommodate up to 16 different DCB's (although there 
may be many more than 16 DCB's defined). The GM DCB is written when the disk 
is first formatted, and all other DCB's may be appended at a later time. 

Figure 2 illustrates a DCB 200 in accordance with the invention. The 
proposed standard specifies a standard header. The header contains three 
information items: (1) a DCB ID number (202), (2) an Unknown Content 
Descriptor Actions (UCDA) area (204), and (3) a vendor ID (206). The remaining 
part 208 of the DCB is specific to the type of DCB identified by the DCB ID 
number. The DCB ID number is a number that must be registered as part of the 
standard. However, as will be discussed in more detail below, new DCB ID's may 
be added during the life of the standard, and it is not necessary for every drive to 
recognize every DCB ID. The proposed standard reserves one 16-bit word for the 
DCB ID. The proposed standard specifies that all DCB blocks are initially 
formatted as all zeros. Therefore, a DCB ID of 0000 hex indicates an unused 
(available) block. If a drive is unable to write a DCB, for example because of a 
media defect, the DCB ID is set to all ones (FFFF hex). If a DCB is no longer 
needed, rather than rewriting the block with all zeros, the DCB ID is set to FFFE 
hex, which indicates the block is available for reuse. Note that because of possible 
media defects, the sequence of DCB's in the lead-in area may be different than the 
sequence of DCB's in the lead-out area. For example, if the first DCB block of the 
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lead-in area is defective, the GM DCB may be the second block in the lead-in area 
but may be the first block in the lead-out area. 

One important feature of a DCB is the second header entry, Unknown 
Content Descriptor Actions (UCDA) 204. The UCDA is used to ensure that even if 
5 a drive does not recognize a DCB ID, the drive does not permit disk access actions 

that are inconsistent with the access control requirements of the unknown DCB. 
This provides some backwards compatibility, a capability that is lacking in many 
current proposed standards. The UCDA will be discussed in more detail below. The 
third and final entry in DCB header is a vendor ID (206). 
iqp Figure 3 illustrates additional detail for the GM DCB (300). The GM DCB 

of course has the standard header (302, 304, 306). The following list of entries in 
'^'^ the GM DCB specific area are intended as illustrations, and the actual list and order 

a 

fU may change as the standard is defined. In the GM DCB-specific area illustrated in 

7" figure 3, the first example entry 308 is a sequence number. The sequence number is 

used for recovery from corrupted data or a power failure, and will be discussed in 

i E s 

C3 more detail below. The second example entry 310 in the GM DCB specific area is a 

ru 

Q media serial number. The third example entry 312 is a load count, which indicates 

'^^ the number of times the medium has been inserted into a drive. Optical disks 

envisioned for use in conjunction with the invention may contain up to 

20 approximately 17 Gigabytes of data. It is expensive, if not impractical, to preformat 

every medium. Accordingly, each medium may be formatted by a drive. It is known 
for optical disk formatting to occur as a background activity when a drive is 
otherwise idle. The fourth example parameter (314) for a GM DCB is a parameter 
that enables background fill (formatting). The next example parameter (316) is a 

25 pointer to the next block that has not been formatted. The drive may also check for 

media defects (certification) in the background by performing a read operation on 
each block after it has been formatted (or perhaps a real-time read-after write 
operation). The sixth example parameter (318) for a GM DCB is a parameter that 
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enables background media certification. The seventh (320) example parameter is a 
pointer to the next block that has not been certified. 

Some present optical disk technologies require that the laser writing power 
be calibrated before writing can occur. In general, the power required is a function 

5 of the specific medium and the particular electronic components in the drive. In 

general, power calibration is time consuming. Another proposed variable (not 
illustrated) in the GM DCB is at least one entry for a drive identification and a 
number designating the laser power resulting when the laser power was calibrated 

^=:^ using the specific medium in the identified drive. A drive recognizing its own ID in 

1^2 the GM-DCB can then simply read the required laser power without having to 

fU recalibrate, 

£3 Operating systems may control whether or not a file can be read or written 

by a user. Some files may be password protected by the operating system. 
s_ Alternatively, write protect for an entire medium may be controlled mechanically. 

|g For example, a sliding tab on a flexible disk cartridge, or a ring inserted into a tape 

I £ 

reel may be used to prevent writing to a medium. In general, if an interchangeable 

p medium is placed into a computer system using an incompatible operating system, 

H 

access control specified by the operating system may be bypassed. For example, if 
one operating system write protects a file, a different operating system may permit 

20 the file to be overwritten. Moving control of access into the drive provides some 

additional protection. Access control within a drive is not new. For example, U.S. 
Patent 5,233,576 (Curtis et al.) describes an optical disk medium in which the 
medium can be partitioned into different portions, and each portion can be defined 
as writable, or read-only. One attractive feature of Curtis et al. is that the method of 

25 write protection works even for legacy drives that were manufactured before the 

new access control method was available. One example DCB for use by the present 
invention takes this general concept even further. One example optional DCB is an 
Access Control (AC) DCB. An access control DCB divides the disk into regions, by 
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specifying starting and ending logical block address or by specifying starting block 
address and number of blocks. Each region, as seen by the operating system, may 
represent a file, a directory, the entire disk, or any other logical storage construct. 
Each region has an associated access control specification, where the access control 
5 specifications include the following, as examples: 

No restrictions 

No read 

No write 

No format 

1 cO Write-once 

fO Read with password 

M 

Write with password 
^'-^ Format with password 



IS 



Appendable with password 



The above list is just a list of examples, and other access controls may be 
desirable. For example, one issue is whether a control attribute specifying a write- 
once region can ever be reversed. The proposed standard specifies that controls can 
be changed, so there are controls on controls. For example, an access control, 
20 within a AC DCB, may itself be password protected. 

Now return to the UCDA (figure 2, 204), The UCDA contains single bit 
fields, where each bit specifies an access control attribute. The UCDA is used only 
when a drive does not recognize a DCB ID, and therefore cannot interpret any 
information, or specifically cannot interpret access control information within the 
25 DCB-specific area of the DCB. When a drive does not recognize a DCB ID, the 

UCDA for the unrecognized DCB overrides all other access controls in all DCB's. 
For example, assume a newly defined DCB specifies that a region of the disk must 
be write protected. The new DCB specifying a write protect region also has a bit set 
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in its UCDA area that specifies no writing. If the drive does not recognize the new 
DCB ID, the drive still sees that the UCDA specifies no writing, and the drive then 
does not permit any part of the disk to be written. This ensures that the drive does 
not perform any access activity that is inconsistent with the access requirements of 
an unrecognized DCB. For an additional example, a unknown DCB may disable 
reading of the DCB specific area of the DCB to ensure that a password in the DCB 
cannot be read by unauthorized drives. Specific UCDA bits may, for example, 
disable writing within the DCB area of the lead-in and lead-out areas, disable 
writing with the data area of the disk, disable writing to any part of the disk, disable 
overwriting of the data area, disable reformatting, disable reading of the data area, 
and so forth. 

Figure 4 illustrates a method for use with the UCDA. A drive first reads the 
DCB ID (step 400). If the drive recognizes the ID (step 402), then the drive uses 
the DCB-specific data area (step 404). If the ID is not recognized (step 402), the 
drive must use the UCDA access control information in the header (step 406). 

Another proposed DCB type is a firmware update DCB. Typically, drive 
firmware is updated by connecting a drive to a computer and having the computer 
send a new version of firmware. Often, it is more convenient if a firmware update 
can occur without involvement by a host computer. It is known for a drive to 
recognize a special medium having a new version of firmware for the drive. The 
drive replaces its existing firmware with the new firmware read from the special 
medium. A DCB may be defined that identifies a medium as a firmware update 
medium, and contains information describing the firmware update, version 
information, back version compatibiity, and so forth. 

Since DCB's are so critical to the proposed standard, it is important to 
provide some protection against a loss-of-power during writing of a DCB, or 
protection against some other corruption of a DCB. As stated above, one redundant 
DCB is written for each DCB. The first word of each DCB-specific data area is a 
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sequence number (figure 3, 308). For example, when a DCB is written for the first 
time, it might have a sequence number of one. Each copy of the DCB receives the 
same sequence number. If the DCB is subsequently updated, the sequence number 
is incremented. Assume, for example, that a DCB having a sequence number of two 
5 is written into the lead-in area, and then power is lost while writing the copy in the 

lead-out area. 

Figure 5 illustrates a method of ensuring that there are always two valid 
copies of each DCB. A drive can check DCB validity by checking the block error 
Q correction data. If both blocks are valid (figure 5, step 502), and if both sequence 

/jp numbers are the same (step 504), then no remedial action is required. If both blocks 

l "^ are valid (step 502), but the sequence numbers are different (step 504), then power 

C3 may have been interrupted before a copy could be made. The copy having the lower 

rU 

,p sequence number is then replaced by the copy having the higher sequence number 

P (step 506). If at least one copy is not valid (step 502), but at least one copy is valid 

^fs (step 508), then the invalid copy is replaced by the valid copy (step 510). If both 

fl 

fU copies are invalid (step 508), then an error condition has occurred, and automatic 

remedial action is not possible. 

From the above, it can be seen that DCB's provide a flexible and standard 
way of providing administration and control information for a data storage medium, 

20 particularly when drives and media may be provided my many different 

manufacturers. In addition, the use of UCDA's provides a standard way of ensuring 
that a drive does not perform an access that is inconsistent with a DCB, even if the 
DCB is not recognized. Finally, redundancy and sequence numbers provide some 
protection against corrupted DCB's. 

25 The foregoing description of the present invention has been presented for 

purposes of illustration and description. It is not intended to be exhaustive or to 
limit the invention to the precise form disclosed, and other modifications and 
variations may be possible in light of the above teachings. The embodiment was 
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chosen and described in order to best explain the principles of the invention and its 
practical application to thereby enable others skilled in the art to best utilize the 
invention in various embodiments and various modifications as are suited to the 
particular use contemplated. It is intended that the appended claims be construed to 
include other alternative embodiments of the invention except insofar as limited by 
the prior art. 
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